home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc782.txt < prev    next >
Text File  |  1994-08-01  |  44KB  |  1,299 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.         A Virtual Terminal Management Model
  11.  
  12.  
  13.  
  14.  
  15.  
  16.         RFC 782
  17.  
  18.  
  19.  
  20.  
  21.  
  22.         prepared for 
  23.  
  24.         Defense Communications Agency
  25.         WWMCCS ADP Directorate
  26.         Command and Control Technical Center
  27.         11440 Isaac Newton Square
  28.         Reston, Virginia 22090
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.         by
  38.         Jose Nabielsky
  39.         Anita P. Skelton
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.         The MITRE Corporation
  47.         MITRE C(3) Division
  48.         Washington C(3) Operations
  49.         1820 Dolley Madison Boulevard
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.                           TABLE OF CONTENTS
  58.  
  59.  
  60.  
  61.                                                                 Page
  62.  
  63.  
  64. LIST OF ILLUSTRATIONS                                             vi
  65.  
  66. 1.0  INTRODUCTION                                                  1
  67. 1.1  The Workstation Environment                                   1
  68. 1.2  Virtual Terminal Management                                   2
  69. 1.3  The Scope                                                     3
  70. 1.4  Related Work                                                  4
  71.  
  72. 2.0  THE VTM MODEL                                                 5
  73. 2.1  The VTM Model Components                                      7
  74. 2.2  The Virtual Terminal Model                                   10
  75.      2.2.1  Virtual Terminal Connectivity                         11
  76.      2.2.2  Virtual Terminal Organization                         11
  77.             2.2.2.1  The Virtual Keys                             12
  78.             2.2.2.2  The Virtual Controller                       12
  79.             2.2.2.3  The Virtual Display                          12
  80.      2.2.3  Virtual Terminal Architecture                         13
  81.             2.2.3.1  Communication Variables                      13
  82.             2.2.3.2  Virtual Display with File Extension          13
  83.             2.2.3.3  Virtual Display Windows                      14
  84. 2.3  The Workstation Model                                        17
  85.      2.3.1  The Adaptation Unit                                   17
  86.      2.3.2  The Executive                                         18
  87.  
  88. REFERENCES                                                        19
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.                                  iii
  107.  
  108.                         LIST OF ILLUSTRATIONS
  109.  
  110.  
  111.  
  112.                                                                 Page
  113.  
  114. Figure Number
  115.  
  116.      2.1       The Virtual Terminal Model                          7
  117.      2.2       The Workstation Model                               8
  118.      2.3       VT 0 (expanded from previous figure)                9
  119.      2.4       The Domains                                        14
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.                                   v
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. 1.0  INTRODUCTION
  166.  
  167.      Recent advances in micro-electronics have brought us to the  age
  168. of the inexpensive, yet powerful, microprocessor.  Closely resembling
  169. the advances of the 1960's which brought about  the  transition  from
  170. batch  processing  to time-sharing, this technological trend suggests
  171. the birth of decentralized architectures where the  processing  power
  172. is  shifted  closer  to  the user in the form of intelligent personal
  173. workstations.  The virtual terminal model described in this  document
  174. caters to this anticipated personal computing environment.
  175.  
  176. 1.1  The Workstation Environment
  177.  
  178.      A personal workstation is a computing engine which  consists  of
  179. hardware  and  software dedicated to serve a single user.  As part of
  180. its architecture, the workstation can invoke the resources of  other,
  181. physically  separate  components, effectively extending this personal
  182. environment well beyond the bounds of the single workstation.
  183.  
  184.      In this personal environment,  processing  resources  previously
  185. shared  among  multiple  users  now become dedicated to a single one,
  186. with a large part of these resources summoned to provide an effective
  187. human-machine  interface.   As a consequence, modalities of input and
  188. output that were unfeasible under the time-shared regime now become a
  189. part of a conversational language  between user and workstation.  Due
  190. to the availability of processing cycles, and the  closeness  of  the
  191. user devices to these cycles, the workstation can support interactive
  192. devices, and dialogue modes using these devices, which could  not  be
  193. afforded before.
  194.  
  195.      The workstation can provide the  user  with  the  mechanisms  to
  196. conduct  several  concurrent  conversations  with user-agents located
  197. elsewhere in the global architecture.   One  such  mechanism  is  the
  198. partitioning  of  the  workstation  physical  display  into  multiple
  199. logical  displays,  with  one  or  more  of  these  logical  displays
  200. providing a dedicated workspace between user and agent.
  201.  
  202.      The nature of the conversations on these logical  displays  need
  203. not  be  limited  to  conventional  alphanumeric  input  and  output.
  204. Conversations using input tools  such  as  positioning  and  pointing
  205. devices  (e.g.,  mouse,  tablet, and such), and using high-resolution
  206. graphics objects for output (e.g., line drawings, raster  blocks  and
  207. images,  possibly  intermixed with text) should be possible on one or
  208. more of these screens.
  209.  
  210.      Moreover, as long as the technological trend  continues  in  its
  211. predicted  path,  one can postulate a workstation which could support
  212. by the mid 1980's multi-media conversations using  voice  and  video,
  213.  
  214.                                   1
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. synchronized   with  text  and  graphics.   At  present,  multi-media
  222. information   management   (i.e.,   acquisition,   processing,    and
  223. dissemination)  is  an  active  research area, but eventually it will
  224. become an engineering problem which, when  solved,  will  add  a  new
  225. dimension  to  already feasible modes of interaction between user and
  226. workstation.
  227.  
  228. 1.2  Virtual Terminal Management
  229.  
  230.      All virtual terminal protocols  (VTPs)  provide  a  vehicle  for
  231. device-independent,     bi-directional,     8-bit    byte    oriented
  232. communications between two VTP users.  Most Vo so by invoking  a
  233. device abstraction of real terminals, called a virtual terminal.
  234.  
  235.      As with a real device, a virtual  terminal  has  a  well-defined
  236. architecture  with  its  own character sets and functions. A VTP uses
  237. the architectural features of  the  virtual  terminal  to  provide  a
  238. common  language,  an  intermediate  representation,  between its two
  239. communicating entities.  However a  VTP  user  does  not  communicate
  240. directly  with  this  virtual  terminal.   A function of a VTP is the
  241. local mapping between the site-specific order codes and  the  virtual
  242. terminal  domain,  thus allowing this adaptation to be transparent to
  243. the VTP users.
  244.  
  245.      The model of a personal workstation as a dedicated  device  with
  246. considerable   resources    affects  the  way  we  conceptualize  the
  247. architecture of virtual terminals,  both  in  breadth  and  depth  of
  248. function.   It also affects the way we view the virtual terminal vis-
  249. a-vis its local correspondents, the personal  workstations,  and  its
  250. remote correspondents, the other virtual terminals.
  251.  
  252.      This document presents a radical view of  virtual  terminals  as
  253. resource  sharing  devices.   The  classical  concept  of  a  virtual
  254. terminal as a two-way device with a  limited  architecture  has  been
  255. dismissed.   Instead,  we  view a virtual terminal as an n-way device
  256. with multiple correspondents sharing access to its virtual "keyboard"
  257. and  "display."  In  this  model, a virtual terminal has two kinds of
  258. correspondents:  adaptation units, and other virtual terminals.   The
  259. adaptation  units  serve  as  interface  agents  between  the virtual
  260. terminal and its users, providing the step transformation between the
  261. user-specific   order   codes  and  the  virtual  terminal  interface
  262. language.  In turn,  the  other  virtual  terminals  are  cooperating
  263. co-equals  of the  virtual  terminal, interacting with it to maintain
  264. global control and data store synchrony. Resembling the administrator
  265. of  a  local  copy  of  a distributed data base, the virtual terminal
  266. interacts with the other virtual  terminals  (the  remote  data  base
  267. managers)  and  with  the  local  adaptation  units  (the  data  base
  268. transformers) to provide read, write, and modify access to its  local
  269.  
  270.                                   2
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280. data  store  (the  local  copy  of  the distributed data base), while
  281. providing concurrency control to maintain a "single user  view"  when
  282. so desired.
  283.  
  284.      To communicate with its correspondents, a virtual terminal  uses
  285. two virtual languages. In the case where the correspondent is another
  286. virtual terminal, it  uses  the  language  of  the  virtual  terminal
  287. protocol;  in the case where the correspondent is an adaptation unit,
  288. it uses an interface language closer to the physical architecture  of
  289. the end-user, but a virtual language nevertheless.
  290.  
  291.      In essence, the virtual terminal has become a device in its  own
  292. right,  free  from  a  single physical realization and also dedicated
  293. ownership. As a result, a single workstation not only may request any
  294. number  of  virtual  terminals,  but  a  number  of  workstations may
  295. share -- and interact with -- a particular virtual terminal.
  296.  
  297.      The functional breadth of virtual terminals has  been  augmented
  298. by  the  concept  of  virtual  terminal  classes.   Each  class is an
  299. abstraction of a particular device architecture.  There  are  stream,
  300. line,  logical  page,  physical page, and graphics virtual terminals,
  301. all made up of:  a class-constrained data structure and its attendant
  302. operations  (the virtual display); a general controlling element (the
  303. virtual controller); and an input selector (the virtual keys).
  304.  
  305.      Finally, the functional depth of the virtual terminal  has  been
  306. extended  by  architectural  features  previously  unavailable.   The
  307. virtual terminal becomes a  multi-user  device  with  a  non-volatile
  308. virtual  display available for selective viewing.  These concepts are
  309. discussed is some detail in the chapter that follows.
  310.  
  311. 1.3  The Scope
  312.  
  313.      An overview of the virtual terminal model and the management  of
  314. communicating  virtual  terminals  is  presented.   A detailed design
  315. description  of  the  data  structures  and  accompanying  addressing
  316. functions  has been completed.  The operations and control mechanisms
  317. are less complete.  Before  the  design  is  solidified,  an  initial
  318. mimimal implementation will be made to validate the model.
  319.  
  320.      This document represents work in progress; current international
  321. interest  in  virtual  terminal  protocols has motivated us to submit
  322. this as an example of  mechanisms  that  a  virtual  terminal  should
  323. support.   The  model  provides a framework for supporting device and
  324. processing  capabilities  not  yet  commonly  available.   A  virtual
  325. terminal  protocol standardization effort may not want to include all
  326. the mechanisms that are described here, but it is our contention that
  327. one should not preclude these extensions for the future.
  328.  
  329.                                   3
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. 1.4  Related Work
  338.  
  339.      The concepts presented in this document  are  the  offspring  of
  340. previous  work  in  the  area  of  personal  computing,  and  of user
  341. interfaces to (distributed) systems.  The bibliography at the end  of
  342. the  document  collects  this  material.  In  particular,  we want to
  343. acknowledge the work done at the University of Rochester  on  virtual
  344. terminals,(6)   work  which  has  influenced to a large degree how we
  345. view user interfaces through a display.
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.                                   4
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. 2.0  THE VTM MODEL
  395.  
  396.      This section describes a virtual terminal management (VTM) model
  397. whose  architecture  not  only  derives  from  a  quest  for  device-
  398. independent, terminal-oriented communications, but  more  importantly
  399. from a desire to provide effective human-machine interfaces.
  400.  
  401.      The VTM architecture  is  a  multi-user  structure  which  spans
  402. several  building blocks. The underlying foundation to this structure
  403. is provided by the cooperating  virtual  terminals.   Under  the  VTM
  404. model,  these  cooperating  virtual  terminals  are  viewed as device
  405. abstractions, all with  a  common  architecture,  exchanging  virtual
  406. terminal  protocol  items  to  update each other's view of the world.
  407. Resting on this foundation lie the adaptation units.  Associated with
  408. a   single   end-user,   an   adaptation   unit   provides  the  step
  409. transformation between user and virtual  domains.   In  a  sense  the
  410. adaptation  unit  is  also  a virtual terminal, although one which is
  411. much closer to the architecture of the end-user.  Finally, on top  of
  412. this  supporting  structure  are  the  end-users, the application and
  413. human processes, all interacting towards a common goal.
  414.  
  415.      Before embarking on a description of the VTM  model  components,
  416. we  present  the  set of capabilities the VTM model provides its end-
  417. users, either human or application.  After all,  the  motivation  for
  418. the  model  and  its  underlying  concepts  stems  from our desire to
  419. provide productive user environments.
  420.  
  421.      HUMAN  <--->  WORKSTATION
  422.  
  423.      o   Multiplexing the workstation physical display both  in  time
  424.          and space.
  425.  
  426.          The workstation assigns to each user conversation a  logical
  427.          terminal  with  a well-distinguished logical display.  Under
  428.          the  user  control,  the  workstation  maps  these   logical
  429.          displays  on  non-overlapping areas of the physical display,
  430.          providing   a   dedicated   workspace   between   user   and
  431.          correspondents.   Limited  only  by the area of the display,
  432.          many logical displays could be  mapped  at  one  time,  each
  433.          providing  display updates when so required.  Since the area
  434.          of the  display  is  a  scarce  resource,  not  all  logical
  435.          displays  need  be  mapped at the same time.  Therefore, the
  436.          workstation may roll-out and roll-in selected displays under
  437.          the  user  control,  thereby  also multiplexing the physical
  438.          display in time.
  439.  
  440.      o   Multiplexing the workstation input devices in time.
  441.  
  442.  
  443.                                   5
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.          The input devices always map to a single  user  conversation
  452.          (i.e.,  a  single  logical terminal).  However, the user can
  453.          select  a  new  logical  terminal   by   some   well-defined
  454.          interaction  (e.g.,  depressing  a  function  key,  using  a
  455.          pointing  device,  and  such),  effectively  switching   the
  456.          ownership of the input tools.
  457.  
  458.      o   Concurrent multi-mode use of the workstation.
  459.  
  460.          The capabilities of the  workstation  limit  the  scope  and
  461.          character   of   the   individual   conversations.   If  the
  462.          workstation  supports   rubout   processing   (i.e.,   erase
  463.          operations  on  lines  and  characters),  then  the  logical
  464.          terminals can be independent,  scrolling  "terminals,"  some
  465.          page-oriented, others line-oriented.  If the architecture of
  466.          the  workstation  supports  graphics  objects  as  primitive
  467.          objects  then so can the individual logical terminals.  As a
  468.          consequence, while some logical  terminal  displays  may  be
  469.          dedicated  to alphanumeric output, others may include raster
  470.          graphics and imaging data together with positioned text.
  471.  
  472.      o   The sharing of  a  single  logical  terminal  among  several
  473.          users.
  474.  
  475.          Several end-users may link to  a  single  logical  terminal.
  476.          All linked parties are viewed by the shared "device" as both
  477.          input sources and  output  sinks.   As  a  consequence  this
  478.          device  sharing  need  not be limited only to the sharing of
  479.          device output. In general, each linked party may  have  full
  480.          read  and  write  access  to  the logical terminal, if it so
  481.          desires.
  482.  
  483.      o   Selective viewing on a logical terminal display.
  484.  
  485.          In the user's view, a logical terminal display  is  a  user-
  486.          specified  window  on  a  potentially  larger structure, the
  487.          "device"  display.   This  window  provides  the  "peephole"
  488.          through  which the device display is viewed.  The portion of
  489.          the device display mapped on this window is not  limited  to
  490.          its   "present   contents."  Under  the  user  control,  the
  491.          workstation may invoke the viewing of  past  activity  on  a
  492.          logical  terminal  display  when  the  device display is I/O
  493.          file-extended.  Since the window mechanism  is  an  integral
  494.          part  of  the  device  architecture,  it is available on all
  495.          logical terminal displays.  Furthermore, the viewing of past
  496.          activity  does  not  affect  others  sharing  access  to the
  497.          device.
  498.  
  499.  
  500.                                   6
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.      o   Discarding, suspending, and resuming the output of a logical
  509.          terminal always under user control.
  510.  
  511.          As part of the  user  interface,  the  workstation  provides
  512.          simple  "keys" through which the user controls the output on
  513.          a logical terminal display.  These workstation  "keys"  need
  514.          not  be  physical  keys, but could be other input tools used
  515.          for this purpose (e.g., analog dials, hit-sensitive areas on
  516.          the  physical display, and such).  In any event, through the
  517.          auspices of the workstation,  the  user's  control  requests
  518.          translate   into   the   proper  commands  to  the  "device"
  519.          associated with the logical terminal.
  520.  
  521.      APPLICATION  <--->  ADAPTATION UNIT
  522.  
  523.      o   A logical view of real devices.
  524.  
  525.          For  each  real   terminal   architecture,   one   canonical
  526.          representation:  a logical device.
  527.  
  528.      o   For  a   particular   logical   device,   several   possible
  529.          interaction paradigms.
  530.  
  531.          Some logical devices are intrinsically half-duplex (e.g.,  a
  532.          page-oriented  logical  device), some are full-duplex (e.g.,
  533.          communicating  processes  using  a  stream-oriented  logical
  534.          device), and some may be either half or full-duplex (e.g., a
  535.          line-oriented logical  device).   Some  full-duplex  logical
  536.          devices  can  provide  no  echoing, remote echoing, or local
  537.          echoing.   Those  that  interface  with  applications   that
  538.          support command completion (e.g., command-line interpreters)
  539.          can shift the locus of echoing as a function  of  a  dynamic
  540.          break character set.
  541.  
  542.      o   One application communicating with several logical devices.
  543.  
  544.          As  part  of  an  application's  model  of  interaction,  an
  545.          application may "own" several logical devices.  For example,
  546.          an editor could use a line-oriented logical device to gather
  547.          top-level  commands,  and  a page-oriented logical device to
  548.          provide editing workspace.
  549.  
  550. 2.1  The VTM Model Components
  551.  
  552.      The virtual terminal management  model  consists  of  two  major
  553. components:   the  virtual  terminal model, and the workstation model
  554. (see Figures 2.1, 2.2, and 2.3 respectively).
  555.  
  556.  
  557.                                   7
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.                               AU1
  575.                                |
  576.                          AU0   |    AU2
  577.                           |    |     |
  578.                          _______________
  579.                          |             |
  580.                          |     VT2     |
  581.                          |             |
  582.                          |             |
  583.                          _______________
  584.                                 |       _______________
  585.                                 |       |             |----AU0
  586.                                 |_______|     VT0     |
  587.                                 |_______|             |
  588.                                 |       |             |----AU1
  589.                                 |       _______________
  590.                                 |
  591.                          ________________
  592.                          |              |
  593.                          |              |
  594.                          |     VT1      |
  595.                          |              |
  596.                          ________________
  597.                           |     |     |
  598.                          AU0    |    AU2
  599.                                 |
  600.                                AU1
  601.  
  602.  
  603. VT = VIRTUAL TERMINAL
  604. AU = ADAPTATION UNIT
  605.  
  606.  
  607.  
  608.                FIGURE 2.1 - THE VIRTUAL TERMINAL MODEL
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.                                   8
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.                     ___  ___               ___  ___
  635.                    |VT1||VT2|             |VT1||VT2|
  636.                    ____ _____             _____ ____
  637.                     |     |                 |    |
  638.                   __|_____|_________________|_____|__
  639.                   | |     | |             | |     |  |
  640.                   |  REMOTE | -CONTROLLER-|  REMOTE  |
  641.                   |   KEYS  |             | DISPLAYS |
  642.                   |         |             |          |
  643.                   | VIRTUAL |             |   DATA   |
  644.                   |   KEYS  |             |  STORE   |
  645.                   |         |<----------->|          |
  646.                   |  LOCAL  |             |   LOCAL  |
  647.                   |   KEYS  |             | DISPLAYS |
  648.                   |         |             |          |
  649.                   __|_____|__________________|_____|__
  650.                     |     |                  |     |
  651.                    ____ ____               _____ ____
  652.                   |AU0||AU1|               |AU0||AU1|
  653.                    ____ ____               _____ ____
  654.  
  655.  
  656.  
  657.           FIGURE 2.2 -- VT0 (expanded from previous figure)
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.                                   9
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.                               +--------------------+
  690.                               |                    |
  691.                             o-|-------------------|
  692.                               |     EXECUTIVE      |
  693.                               |--------------------|
  694.    Screen        +-------+  o-|--------------------|      +-----+
  695. +---------+     /|OUTPUT |    |  ADAPTATION UNIT 0 |<---->| VT0 |
  696. |EXECUTIVE|    / |       |<---|--------------------|      +-----+
  697. |---------|   /  |HANDLER|  o-|--------------------|      +-----+
  698. |   AU0   |  /   |-------|    |  ADAPTATION UNIT 1 |<---->| VT1 |
  699. |---------| /    | INPUT |    |--------------------|      +-----+
  700. |   AU1   |/     |       |  o-|--------------------|
  701. |---------|      |HANDLER|    |         .          |
  702. |         |      |    /--|o   |         .          |
  703. ~         ~      +-------+   ~         .          ~
  704. ~         ~         /        ~                    ~
  705. |---------|        /        o-|--------------------|      +-----+
  706. |   AUK   |       /           |  ADAPTATION UNIT K |<---->| VTK |
  707. +---------+      /            +--------------------+      +-----+
  708.                 /             |                    |
  709. +---------+    /              +--------------------+
  710. |Keyboard |   /
  711. +---------+  /
  712. |[] [] [] | /
  713. |[] [] [] |/
  714. +---------+
  715.  
  716.  
  717.  
  718.                  FIGURE 2.3 - THE WORKSTATION MODEL
  719.  
  720.  
  721.  
  722. The first component embodies the canonical device, while  the  second
  723. component   includes   the   adaptation   unit   and  its  associated
  724. environment.  Each component will be described in turn below.
  725.  
  726. 2.2  The Virtual Terminal Model
  727.  
  728.      The objective of virtual terminal protocols is  to  provide  the
  729. users  of  the service with a common, logical view of terminals.  The
  730. common user  view  is  attained  through  a  standard,  protocol-wide
  731. representation  of  a canonical terminal, the virtual terminal.  This
  732.  
  733.                                  10
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741. permits the exchanges between users of the protocol  to  be  free  of
  742. device-specific encodings.
  743.  
  744.      The design postulates an integrated virtual terminal model which
  745. extends  the  nature  and  scope  of this canonical device in several
  746. important ways.  The major aspects of the  model,  its  connectivity,
  747. its organization, and its architecture are described below.
  748.  
  749.      2.2.1  Virtual Terminal Connectivity
  750.  
  751.      Most virtual terminal protocols only cater to two-way  dialogues
  752. in  which  a  single  virtual  terminal  terminates  each  end of the
  753. communication path.
  754.  
  755.      We define the virtual terminal as a n-way device  where  one  or
  756. more  of  the  correspondents  to  this device are local users of the
  757. service, and the remaining correspondents (if any) are  peer  virtual
  758. terminals.   Each  correspondent  to the virtual terminal has its own
  759. bi-directional path to produce virtual input to, and receive  virtual
  760. output from, the virtual terminal.  This bi-directional path provides
  761. the vehicle for a virtual terminal session between user  and  virtual
  762. terminal.   Globally, the cooperating virtual terminals and these bi-
  763. directional paths span a dendritic (tree-like) topology.
  764.  
  765.      It is important to note  that  we  have  decoupled  the  virtual
  766. terminal  from  its  physical  realization,  a  single real terminal.
  767. Indeed, a virtual terminal does not map necessarily to just one  real
  768. device, but possibly to many real devices.
  769.  
  770.      The virtual terminal is viewed ultimately as a well-defined data
  771. structure  which  provides  its  correspondents  with a non-dedicated
  772. virtual terminal service.  And these  correspondents  may  have  read
  773. only, write only, or read/write access rights to this data structure.
  774.  
  775.      2.2.2  Virtual Terminal Organization
  776.  
  777.      The virtual terminal is an abstraction;  its  organization,  the
  778. building  blocks which make up the virtual terminal, is the result of
  779. a feature extraction of the real terminal  that  it  is  tailored  to
  780. support.
  781.  
  782.      We have conceptualized the virtual terminal as  a  meta-terminal
  783. (i.e.,  the terminal of terminals).  The meta-terminal is composed of
  784. three well-distinguished building  blocks: virtual  keys,  a  virtual
  785. controller, and a virtual display.
  786.  
  787.  
  788.  
  789.  
  790.                                  11
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.      2.2.2.1  The Virtual Keys.  The analog of the  virtual  keys  is
  798. the  physical keyboard of real terminals.  However, while the keys of
  799. a physical terminal are controlled by a single manual process,  these
  800. virtual  keys  can be activated by multiple, concurrent entities (the
  801. virtual terminal correspondents).  Each correspondent of the  virtual
  802. terminal, be it a user of the service or a peer virtual terminal, has
  803. its input stream to the meta-terminal terminated at the virtual keys.
  804. The  virtual  keys  provide the control of access of input streams to
  805. the meta-terminal.
  806.  
  807.  
  808.      2.2.2.2    The Virtual Controller.    The   virtual   controller
  809. provides   virtual  terminal  session  management.   It  manages  the
  810. establishment and termination of a virtual terminal  session  with  a
  811. correspondent; supports the possible negotiation and renegotiation of
  812. the session  attributes;  and  enables  the  deactivation  and  later
  813. activation  of  the  session.   The  virtual controller also provides
  814. virtual terminal  signalling  control  by  managing  the  out-of-band
  815. signals addressed to the virtual terminal.
  816.  
  817.  
  818.      2.2.2.3   The Virtual Display.   The  virtual  display  is   the
  819. dynamic  component in the meta-terminal organization.  For each class
  820. of  real  device  (e.g.  stream,  line,  page,  or  graphics-oriented
  821. devices)  there  is  a  corresponding  virtual  terminal  class.  The
  822. organization  of  the  virtual  terminal  data  structure  is  class-
  823. specific.  A virtual terminal models a particular terminal class when
  824. it is 'fitted' with the proper  data  structure  manager  or  virtual
  825. display.   This  binding  need  not  be  static  (e.g.,  a line-class
  826. specialist, and so forth), but could be result of decisions  made  at
  827. "run-time" by applying the principle of negotiated options.
  828.  
  829.      The virtual display manages the data structure  associated  with
  830. the  meta-terminal  and  performs  operations on the control and data
  831. elements  of  the  structure.  As  a  direct  consequence  of   these
  832. operations  on  the meta-terminal data structure, the virtual display
  833. may  generate  display  updates  to  one,  some,  or   all   of   the
  834. correspondents.  All virtual terminal output streams originate at the
  835. virtual display.
  836.  
  837.      Different virtual terminal  classes  are  spawned  by  different
  838. "kinds" of virtual displays, and this is realized in one of two ways.
  839. For character-oriented virtual devices,  it  is  possible  to  use  a
  840. single,  wide-scoped  virtual  display with a character-oriented data
  841. structure by constraining it to conform to the model  of  the  device
  842. class (e.g., line-oriented devices must be constrained to line-access
  843. rules).  For non character-oriented virtual devices  (e.g.,  graphics
  844. devices),  an  altogether different virtual display must be used with
  845.  
  846.                                  12
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853. properties better suited for the new domain (e.g., a graphics virtual
  854. display based on a structured display file).
  855.  
  856.      2.2.3  Virtual Terminal Architecture
  857.  
  858.      The commands, and associated parameters, which are available  to
  859. the  users  of  the  virtual terminal constitute the virtual terminal
  860. architecture.  The commands available to a user  --  to  request  the
  861. virtual  controller  to  establish,  abort,  or  close a session, and
  862. discard, suspend, or resume output -- remain invariant to the virtual
  863. terminal  class.  However, as one would expect, the user interface to
  864. the virtual display depends on the nature of this data structure.
  865.  
  866.      Three important architectural features of the meta-terminal are:
  867. the concept of communication variables, the notion of a file-extended
  868. virtual display, and the concept of virtual display windows. Each  of
  869. these  concepts  are a part of the meta-terminal architecture because
  870. they are apparent to the users of the virtual terminal.
  871.  
  872.  
  873.      2.2.3.1  Communication Variables.  Each component of  the  meta-
  874. terminal  (i.e.,  virtual  keys,  controller,  display) is assigned a
  875. standard, protocol-wide name which we call a communication  variable.
  876. The communication variable is a part of the header of each command to
  877. the  virtual  terminal  (i.e.  protocol  item).   It  permits  better
  878. management  of  the  virtual  terminal  command  name space, and also
  879. provides the virtual keys  with  an  easy  mechanism  to  select  the
  880. destination  of  the  request.   It must be noted that nothing in the
  881. model precludes the addition of more virtual entities  to  the  meta-
  882. terminal,  such  as auxiliary virtual devices and signalling devices.
  883. The use of communication variables provides a naming hierarchy  which
  884. alleviates   the  problems  of  device  selection  and  command  name
  885. allocation in the case of such extensions.
  886.  
  887.  
  888.      2.2.3.2    Virtual Display with File Extension.    The   virtual
  889. display is the immediate manager of the meta-terminal data structure.
  890. When the virtual display is provided with an I/O file  extension,  it
  891. is   possible  to  introduce  the  concept  of  a  stable-store  data
  892. structure, a data structure whose  contents  are  stored  in  backing
  893. store  (e.g.,  disk).   If  the virtual display is provided with this
  894. file  extension  capability  (a  local  option  with  no   end-to-end
  895. significance),  then  the  meta-terminal  data structure inherits the
  896. spatial and temporal attributes (dimensions and time-to-live) of  the
  897. associated file.  Such a virtual display, coupled with the concept of
  898. virtual display windows below, provides the users of the service with
  899. a very powerful tool.
  900.  
  901.  
  902.                                  13
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.      2.2.3.3  Virtual Display Windows.  To communicate with a virtual
  910. terminal,  each  real device uses an adaptation unit as its interface
  911. entity (this adaptation unit is a part of the workstation model,  see
  912. section  2.3).  What is important to note is that the adaptation unit
  913. provides the  transition  between  the  device-specific  domain,  the
  914. device workspace,  and  the virtual domain, the master workspace (see
  915. Figure 2.4).
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.                                  14
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  |                                 |                                   |
  967.  |        VIRTUAL TERMINAL         |         ADAPTATION UNIT           |
  968.  |<------------------------------->|<--------------------------------->|
  969.  |             DOMAIN              |              DOMAIN               |
  970.  |                                 |                                   |
  971.  
  972.  + - - - - - - - - - +   + - - - - - - - - - +        - - - - - - - - -
  973.  |  +--->  x(m)      |   |                   |       /                /|
  974.  |  |                |   |            x(i)   |      /                / |
  975.  |  v  y(m)          |   | +---------------> |      - - - - - - - - -  |
  976.  |                   |   | |              |  |     | +------------+ |  |
  977.  | +--------------+  |   | |              |  |     | | VIEWPORT 1 | |  |
  978.  | |              |  |   | |              |  |     | |            | |  |
  979.  | |              |  |   | |              |  |     | |            | |  |
  980.  | |              |  |   | |              |  |     | |            | |  |
  981.  | |              |  |   | |              |  |     | |            | |  |
  982.  | |              |  |   | |   A<---------|--|-----|-|->A         | |  |
  983.  | |              |  |   | |  / \         |  |     | |            | |  |
  984.  | |     <--------|--|---|-|->   \        |  |     | |            | |  |
  985.  | |    /         |  |   | |      \       |  |     | |        <---|-|--|+
  986.  | |    A         |  |   | |       \      |  |     | +------------+ |  ||
  987.  | |              |  |   | |        \     |  |     |                |  ||
  988.  | |     WINDOW   |  |   | |         \    |  |     | +------------+ |  ||
  989.  | |              |  |   | |          \   |  |     | | VIEWPORT 2 | |  ||
  990.  | |              |  |   | |-----------\--+  |     | |            | |  ||
  991.  | |              |  |   | |            \    |     | |            | |  ||
  992.  | +--------------+  |   | v  y(i)       \   |     | +------------+ |  ||
  993.  |                   |   |                \  |     |                | / |
  994.  |                   |   |                 \ |     |                |   |
  995.  |                   |   |                  \|      - - - - - - - -     |
  996.  |     /             |   |       /           |            |  |          |
  997.  + - -/- - - - - - - +   + - - -/- - - - - - +\           |  |          |
  998.      /                         /               \     - - - - - - - -    |
  999.     /                         /                 \   |    KEYBOARD   |   |
  1000.   MASTER WORKSPACE         INSTANCE WORKSPACE    \  + - - - - - - - +   |
  1001.                                                   <-/   []  []  [] /|   | 
  1002.                                                    /   []  []  [] / |   |
  1003.                                                   + - - - - - - - - +   |
  1004.                                                                         |
  1005.                                             PHYSICAL DEVICE WORKSPACE --+
  1006.  
  1007.  
  1008.                            FIGURE 2.4 -- THE DOMAINS
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.                                  15
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023. However  a  device  need  not  be  interested  in  the  whole  master
  1024. workspace,  only  in  a  portion  of  it.   As  part  of  its session
  1025. attributes, each adaptation unit has a window, a  rectangular  region
  1026. in  the  virtual  display, which delimits its area of interest in the
  1027. master.  This portion of the master domain will be  referred  as  the
  1028. instance workspace.   Then,  for  each  adaptation  unit, there is an
  1029. instance workspace whose spatial attributes (dimension  and  position
  1030. within the master) are those of its window definition.
  1031.  
  1032.      All adaptation  units  communicate  with  the  virtual  terminal
  1033. "relative"  to  their  own instance workspace.  As far as the virtual
  1034. terminal is concerned,  each  instance  workspace  defines  a  "real"
  1035. terminal,  although in fact it is just an intermediate representation
  1036. of the real device.   In  essence,  the  instance  workspace  is  the
  1037. coordinate  space  where  both  virtual  terminal and adaptation unit
  1038. rendezvous. (See section 2.3 for a discussion of  how  this  instance
  1039. workspace is mapped onto the device workspace).
  1040.  
  1041.      The window dimensions are the exclusive choice of the adaptation
  1042. unit  that  owns  it.   With  these  dimensions  the  adaptation unit
  1043. specifies to the virtual terminal how much of the  master  is  to  be
  1044. viewed; data  elements  not  contained  within  the boundaries of the
  1045. window are clipped.  Varying the dimension of the window  results  in
  1046. corresponding changes on the amount of the master that is viewed.
  1047.  
  1048.      In contrast, the position of the window on the master might  not
  1049. be  under  direct  control of the adaptation unit.  To understand the
  1050. dynamics of a window, we introduce the notion of a master cursor  and
  1051. an instance cursor.  The master cursor is a read/write pointer, which
  1052. is a part of the virtual display architecture.  In turn, the instance
  1053. cursor  is a pointer owned by the adaptation unit, which is a part of
  1054. the state information maintained by the virtual  display.   Normally,
  1055. both master and instance cursors are bound together so that motion of
  1056. one cursor translates into an equivalent motion  of  the  other.   As
  1057. long  as  the adaptation unit does not explicitly unbind its instance
  1058. cursor from the master cursor, the active region of the master (i.e.,
  1059. the position where the master cursor lies) is guaranteed to be always
  1060. within the instance  space,  and  thus  viewable.   This  means  that
  1061. certain  operations  on  the virtual display will implicitly relocate
  1062. the window of an adaptation unit within  the  bounds  of  the  master
  1063. workspace  to  insure the tracking of the master cursor.  (The actual
  1064. algorithm which enforces  this  tracking  rule,  called  the  viewing
  1065. algorithm,  has  not  been included here.)  This window relocation is
  1066.  
  1067.  
  1068.                                  16
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075. viewed  at  the  real  terminal  as  either  vertical  or  horizontal
  1076. scrolling.
  1077.  
  1078.      However, an adaptation unit has the choice to bypass  this  rule
  1079. by detaching its instance cursor from the master, effectively getting
  1080. complete control of its cursor to view other portions of  the  master
  1081. space.   If  the  virtual display has an I/O file extension, then the
  1082. adaptation unit can pan its window on the  file-extended  space  well
  1083. beyond  the  present  contents of the master space.  Therein lies the
  1084. power of a stable-store data structure when coupled with the  concept
  1085. of windowing.
  1086.  
  1087. 2.3  The Workstation Model
  1088.  
  1089.      The workstation model is composed  of  one  or  more  adaptation
  1090. units,  and  a workstation monitor, which we will call the executive.
  1091. Each will be  described  in  turn  below.   In  addition,  the  model
  1092. includes  input  and output handlers, and an underlying multi-tasking
  1093. operating system of unspecified architecture.
  1094.  
  1095.      2.3.1  The Adaptation Unit
  1096.  
  1097.      An adaptation unit embodies an instance of a  virtual  terminal,
  1098. and  since  the  workstation model postulates possibly many different
  1099. such  instances  per  physical  workstation,  then  potentially  many
  1100. adaptation units will be co-located at a workstation.
  1101.  
  1102.      The adaptation unit can be viewed as the workstation agent which
  1103. provides the mapping between instance workspace and device workspace.
  1104. To define this mapping, we introduce the notion of a  viewport  as  a
  1105. rectangular  area of the physical screen allocated for the viewing of
  1106. a virtual terminal instance.  An adaptation  unit  has  the  task  of
  1107. mapping  the  totality of the instance workspace onto the viewport, a
  1108. mapping which is a device-specific concern totally removed  from  the
  1109. domain  of  discourse  of the virtual terminal.  Thus the position of
  1110. the viewport determines the relocation of the selected data structure
  1111. elements   on  the  viewing  unit,  and  the  viewport  dimensions  a
  1112. (potential) scaling transformation.
  1113.  
  1114.      The adaptation unit also produces virtual input to  the  virtual
  1115. terminal   by  translating  the  user  input  into  virtual  terminal
  1116. commands.  It implements the service side of  the  interface  to  the
  1117. virtual terminal.
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.                                  17
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.      2.3.2  The Executive
  1132.  
  1133.      This conceptual entity performs the task and resource management
  1134. required to create and destroy virtual terminal instances, and to map
  1135. these virtual terminal instances to the screen viewports.
  1136.  
  1137.      It must provide at least a minimal  user  command  interface  so
  1138. that  its  tools may be accessed (one of them being the management of
  1139. screen real estate).
  1140.  
  1141.      Finally, the executive provides the mechanism for  the  end-user
  1142. to  switch  viewport  contexts  through  the use of some input device
  1143. (e.g., function key, pointing or positioning  device).   Following  a
  1144. user  interaction  which indicates a change of context, the executive
  1145. makes the newly selected  virtual  terminal  instance  the  dedicated
  1146. owner of the input devices.
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.                                  18
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.                              REFERENCES
  1188.  
  1189.  
  1190.  
  1191. 1.   R. Bisbey II and D. Hollingworth.   "A  distributable,  display-
  1192.      device-independent  vector  graphics  system  for  the  military
  1193.      command   and   control   environment,"   Information   Sciences
  1194.      Institute, Marina del Rey, California, April 1978.
  1195.  
  1196. 2.   Alan Branden, et al.  "Lisp Machine Project Report,"  Artificial
  1197.      Intelligence  Laboratory, Massachusetts Institute of Technology,
  1198.      AIM 444, August 1977.
  1199.  
  1200. 3.   John Day.  "TELNET Data Entry  Terminal  Option,"  ARPA  Network
  1201.      Working   Group   RFC   732,  Network  Information  Center,  SRI
  1202.      International, September 1977.
  1203.  
  1204. 4.   Douglas Gerhart and D. L. Parnas.  WINDOW  A  formally specified
  1205.      graphics based   text   editor,   Computer  Science  Department,
  1206.      Carnegie-Mellon University, June 1973.
  1207.  
  1208. 5.   B. W. Lampson and R. F. Sproull, "An Open Operating System for a
  1209.      Single-User  Machine,"  Proc  7th Symposium on Operating Systems
  1210.      Principles 9-17, ACM, December 1979.
  1211.  
  1212. 6.   Keith Lantz.  Uniform Interfaces for Distributed Systems,  Ph.D.
  1213.      thesis, University of Rochester, Rochester, N.Y., May 1980.
  1214.  
  1215. 7.   Mathis, J.E., et al, "Terminal Interface Unit Notebook,"  Volume
  1216.      2, ARPA Order No. 2302, SRI Project No. 6933, SRI International,
  1217.      Menlo Park, California, 1979.
  1218.  
  1219. 8.   Allen Newell, Scott  Fahlman,  Bob  Sproull.   "A  Proposal  for
  1220.      Personal  Scientific Computing," Department of Computer Science,
  1221.      Carnegie-Mellon University, July 1979 (DRAFT).
  1222.  
  1223. 9.   "PERQ,"  Three  Rivers  Computer  Corp.,  160  N.   Craig   St.,
  1224.      Pittsburgh, Pa. 15213.
  1225.  
  1226. 10.  Jon  Postel  and  Dave  Crocker.   "TELNET   Remote   Controlled
  1227.      Transmission and Echoing Option," ARPA Network Working Group RFC
  1228.      726, Network Information Center, SRI International, March 1977.
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.                                  19
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243. 11.  John F. Shoch and Jon A. Hupp.  "Notes on the 'Worm'  programs -
  1244.      - some  early  experience with a distributed computation," Xerox
  1245.      Palo Alto Research Center publication  SSL-80-3.   Presented  at
  1246.      the  Workshop  on  Fundamental  Issues in Distributed Computing,
  1247.      ACM/SIGOPS and ACM/SIGPLAN, December 1980.
  1248.  
  1249. 12.  R. F. Sproull and E. L. Thomas.  A  network  graphics  protocol,
  1250.      Computer Graphics 8(3), Fall 1974.
  1251.  
  1252. 13.  C. P. Thacker, E. M. McCreight, B. W. Lampson,  R.  F.  Sproull,
  1253.      and  D. R. Boggs.  "Alto: A Personal Computer." D. Siewiorek, C.
  1254.      G. Bell,  and  A.  Newell,  Computer  Structures   Readings  and
  1255.      Examples, editors, second edition, McGraw-Hill, 1979.
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.                                  20
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.  
  1299.